home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Standards 1994 January / InfoMagic Standards - January 1994.iso / inet / iesg / 91_08_15 < prev    next >
Text File  |  1993-02-04  |  14KB  |  348 lines

  1.  
  2.  
  3.                      IETF STEERING GROUP (IESG)
  4.  
  5.                   REPORT FROM THE TELECONFERENCE
  6.  
  7.                        AUGUST 15TH, 1991
  8.  
  9.  
  10.          Reported by:
  11.          Greg Vaudreuil, IESG Secretary
  12.  
  13. This report contains
  14.  
  15.         - Meeting Agenda
  16.         - Meeting Attendees
  17.         - Meeting Notes
  18.  
  19. Please contact IESG Secretary Greg Vaudreuil
  20. (iesg-secretary@nri.reston.va.us) for more details on any particular topic.
  21.  
  22.  
  23. ^L
  24.  
  25. A.  Meeting Attendees
  26.  
  27.     Almquist, Philip / Consultant
  28.     Borman, David / CRAY
  29.     Callon, Ross / DEC
  30.     Chiappa, Noel / Consultant
  31.     Crocker, Dave / DEC
  32.     Crocker, Steve / TIS
  33.     Coya, Steve / CNRI
  34.     Davin, Chuck / MIT
  35.     Gross, Philip / ANS
  36.     Hobby, Russ / UC-DAVIS
  37.     Hinden, Robert / BBN
  38.     Vaudreuil, Greg / CNRI
  39.  
  40. Regrets
  41.  
  42.     Estrada, Susan / CERFnet
  43.     Reynolds, Joyce / ISI
  44.     Stockman, Bernard / SUNET/NORDUnet
  45.  
  46. B. Agenda
  47.  
  48. 1) Administrivia
  49.  - Bash the Agenda
  50.  - Approval of Minutes
  51.    - July 25th
  52.    - July 30-Aug 2nd
  53.    - August 8th
  54.  
  55. 2) Review of Action Items
  56.  
  57. 3) Protocol Actions
  58.      - MIB 2
  59.      - Concise MIB
  60.      - Network Time Protocol
  61.      - Multi-protocol interconnect over Frame Relay
  62.      - Inverse ARP
  63. 4) RFC Editor Actions
  64.    - Message Send Protocol 2
  65.    - SNMP over OSI
  66.  
  67. 5) Technical Management Issues
  68.    - TCP Large Windows extensions
  69.    - Many MIBs
  70.    - Distinguished Names
  71.    - Five Full-Day IETF Meetings
  72.  
  73. 1. Administrivia
  74.  
  75. 1.1 Approval of the Minutes
  76.  
  77. 1.1.1 July 25th.  The Minutes of the July 25th Teleconference were
  78. approved pending changes to be sent to Vaudreuil by Monday.
  79.  
  80. 1.1.2 Plenary Meetings.  These minutes were approved by the IESG
  81. pending changes to be send to Vaudreuil by Monday.  The Chairman later
  82. asked that these be delayed pending his review and approval.
  83.  
  84. 1.1.3 August 8th.  These minutes were not approved by the IESG.  They
  85. will be read, corrected, and resubmitted for the next teleconference.
  86.  
  87. The IESG discussed the imminent release of the minutes beginning with
  88. the plenary session meetings.  The preferred distribution mechanism was
  89. chosen to be a sister directory to the ietf and internet-drafts, with
  90. an announcement sent to the IETF mailing list of their availability.
  91.  
  92. ACTION: Vaudreuil -- Make a new distributed directory for the IESG
  93. minutes. Insure that mail access is available at the NIC.DDN.MIL
  94.  
  95. 2. Review of selected action items.
  96.  
  97. (89) Apr 25 [Russ Hobby]
  98.          Resolve the conflict with the two version of the IMAP 
  99.          protocol.
  100.  
  101. There is slow progress being made.  One party is now willing to change
  102. the name of the protocol and declare a split.  The other party is
  103. talking in good faith to resolve this issue and may also agree to a
  104. name change.
  105.  
  106. (170) Aug 08 [Phill Gross]
  107.          Communicate the opinion of the IESG concerning the
  108.          Interactions of BGP with IGP's to the authors of the BGP
  109.          Usage document and integrate the useful Interaction
  110.          information into the document.
  111.  
  112. Phill Gross has been in contact with Yackov Rekhter and is
  113. awaiting comments on the latest version of the document.  The IAB is
  114. continuing to send mixed signals on the BGP usage document.  After
  115. significant discussion, the IESG determined that it has done all it
  116. can to address the IAB's concerns on this document.
  117.  
  118. Specific objections were raised about the lack of a routing
  119. architecture document for BGP. While the IESG agrees that there is a
  120. pressing need for an unified routing architecture, it feels that this
  121. document is not required for specific routing protocols, and imposing
  122. this requirement on the BGP protocol designers would unduly delay the
  123. well deserved advancement of the BGP protocol.
  124.  
  125. The IESG agreed to send the current set document to the IAB as soon as
  126. all the authors are polled.  If at that point the IAB still has
  127. objections, these should be send to the IESG and IETF in the form of
  128. an explicit rejection notice.
  129.  
  130. ACTION: Gross -- Send a note the IAB soliciting final comments on the
  131. BGP documents.  Explain that the IESG is satisfied with the current
  132. BGP documents expects to make a public recommendation in the near
  133. future. 
  134.  
  135.  
  136. (168) Aug 08 [Phill Gross]
  137.          Write a statement to the IAB expressing the need felt by the
  138.          IESG for a public response to the public IESG recommendations
  139.          to the IAB.
  140.  
  141. This action is still pending.  The IESG discussed and reiterated the
  142. need for these formal exchanges and notification of standards actions.
  143.  
  144. 3. Protocol Actions
  145.  
  146. 3.1 Management Information Base II
  147.  
  148. The IESG approved the recommendation elevating MIB II to full Standard
  149. status.  MIB II is widely implemented in network devices and
  150. management stations. 
  151.  
  152. 3.2 Concise MIB Definitions
  153.  
  154. The IESG approved the recommendation elevating the Concise MIB
  155. definitions to Draft Standard.  This new compact machine readable
  156. syntax is used in all recent MIBs written, including MIB II. 
  157.  
  158. 3.3 Network Time Protocol Version 3
  159.  
  160. The IESG approved the recommendation for the Network Time Protocol
  161. Version 3 for Proposed Standard.  While there was sentiment within the
  162. IESG for skipping the proposed standard state for this particular
  163. protocol, wowever it was feared that figuring out the rational for an
  164. exception in the understood practice may take far longer than the 6
  165. months the protocol would otherwise remain in the Proposed Standard
  166. state.
  167.  
  168. 3.4 Multi-protocol Interconnect over Frame Relay
  169.  
  170. The IESG discussed this document, and found it to be a good
  171. specification.  One policy concern was raised, and should be
  172. communicated with the author.  Historically the IAB has standardized
  173. IP on top of networking technologies and has avoided standardizing
  174. protocols for running other protocols over these networking
  175. technologies.  An exception has been made for the point to point
  176. protocol where no other standard multi-protocol point to point
  177. protocol was available.  In this case the IAB will assign protocol
  178. numbers and will likely standardize the specification of third party
  179. protocols over PPP.  In the case of Frame Relay, it is not clear who
  180. "owns" the specification.  Normally the IAB would standardize only IP
  181. over Frame Relay.  In addition to specifying IP over Frame Relay, this
  182. document also specifies the general case of Foo over Frame Relay.
  183. Given the uncertain ownership of the frame relay specification, and
  184. the need for multi-vendor interoperation, the IESG has no problem with
  185. this specification.  It is recommended that the title be changed to
  186. reflect the more traditional standardization emphasis of IP over Foo,
  187. such as "IP and other protocols over Frame Relay".
  188.  
  189. ACTION: Vaudreuil -- Talk to author of the Multi-protocol Interconnect
  190. document about the name of this document; report results to IESG.
  191.  
  192. 3.5 Inverse ARP
  193.  
  194. The IESG discuss this document.  While the protocol accomplishes that
  195. specific task it was written to, it is not clear from the document why
  196. a new protocol was needed.  Other address resolution mechanisms exist.
  197. The IESG has been convinced that the Inverse ARP protocol is in fact
  198. a good way to proceed with the specific requirement posed by Frame
  199. Relay networks.  
  200.  
  201. The IESG recommends to the author that a section documenting the
  202. design criterion and rational for this new protocol be written to
  203. capture the reasoning behind this novel extension of the architecture.
  204.  
  205. ACTION: Vaudreuil -- Talk to the author of the Inverse ARP protocol
  206. about the need for a section documenting the design criterion and
  207. rational for the Inverse ARP protocol.
  208.  
  209. ACTION: Vaudreuil -- Encourage the writing of a rational section for
  210. the Inverse ARP document.
  211.  
  212. MAYBE-POSITION: A rational should be captured in Internet Drafts.
  213. Need to avoid a making this a major burden.  It helps capture for
  214. future readers who may not know the word of mouth history.
  215.  
  216. 4. RFC Editor Actions
  217.  
  218. 4.1 Message Send Protocol
  219.  
  220. The RFC editor sent the IESG an experimental protocol, the Message
  221. Send Protocol for review and comment on August 13th.  The IESG found
  222. the document interesting but members did not have time to review this
  223. before todays meeting.  This protocol may impact the SMTP extensions
  224. work with regard to the SEND command.
  225.  
  226. ACTION: Hobby -- Review the Message Send Protocol for the RFC Editor
  227. before August 27th.
  228.  
  229. 4.2 Finger 
  230.  
  231. The RFC Editor has received a new version of the Finger protocol.
  232. This revision corrects inconsistencies between the protocol and common
  233. implementations.  Hobby reviewed the protocol and found the protocol
  234. to be consistent with current practice, and recommends republication
  235. at the current Draft Standard State.
  236.  
  237. The RFC Editor forwarded to the IESG a message from an implementor
  238. of the protocol who has identified several other minor points that
  239. could use clarification.
  240.  
  241. ACTION: Hobby -- Look at the list of enhancements for the Finger
  242. protocol and determine if these should be corrected in this re-release.
  243.  
  244. 4.3 SNMP over OSI
  245.  
  246. Marshall Rose has submitted a new version of the SNMP over OSI
  247. experimental protocol specification.  The intent is in part to provide
  248. a template for future authors to use in writing SNMP over Foo protocol
  249. documents.  The question was raised about whether these SNMP over FOO
  250. are in fact experimental or Standards Track specifications.  The
  251. Network Management Directorate clearly believes that SNMP should be
  252. run only over UDP, and has enunciated that position in Internet Draft 
  253. <draft-ietf-snmp-commservices-00.txt>.  The question remains as
  254. community support for using SNMP over proprietary network technology
  255. grows.
  256.  
  257. Due to lack of time, the IESG was unable to discuss this in greater
  258. depth.
  259.  
  260. ACTION: Vaudreuil -- Schedule time in a future teleconference to
  261. discuss the wisdom of running SNMP only over UDP.
  262.  
  263. 5. Technical Management Issues
  264.  
  265. 5.1 Multitude of MIBs
  266.  
  267. There is a half a dozen MIB's that have been reported out of the
  268. working group and are now being reviewed by the Network Management
  269. Directorate.  The IESG Secretary has been tracking these as IESG
  270. protocol actions.  This newly improved MIB tracking has made clear an
  271. element of confusion. MIBs generally receive their Network Management
  272. Directorate review after the relevant WG has reached closure on the
  273. MIB. Confusion arises when WGs chartered outside the NM area submit
  274. MIBs directly to the IESG without first submitting them for NM review.
  275. This confusion leads to an increasing number of situations in which
  276. the directorate is asked to conduct hasty reviews in order that the
  277. perceived timetable of IESG business not be unduly delayed, rather
  278. than conducting these reviews as part of the normal, 4-month cycle of
  279. NM directorate business.
  280.  
  281. The NM AD expressed the view that, for tracking purposes, the NM
  282. review should be regarded as a distinct step between WG closure on a
  283. MIB and its submission to the IESG. In this way, time invested for the
  284. NM review would be accounted as part of routine progression of the
  285. document, and the quality of the review itself would not suffer from
  286. the time pressures of being a part of the IESG consideration of the
  287. document, which often has very different requirements.
  288.  
  289. 4.2 TCP Large Windows
  290.  
  291. Dave Borman gave a review of the TCP Extensions for Large Windows
  292. protocol situation. The current status is a bit unclear at this time.
  293. It appears that Braden, acting as the executive director of the IAB
  294. rejected the protocol for proposed standard for the IAB and has
  295. reassigned control for further evolution of the protocol to the End to
  296. End research group of the IRTF.  This situation is not normal.  
  297.  
  298. Borman discussed the specific technical problems with the extensions,
  299. and discovered that both the CRAY implementation and the LBL
  300. implementation of this protocol interpret the documents differently.
  301. Borman feels that the protocol needs a bit more engineering, but is
  302. essentially functional as demonstrated by the error free
  303. interoperation between the two independent implementations. A question
  304. was raised about the proposed standard status.  There was the notion
  305. that a proposed standard needs a credible specification, but does not
  306. need to be perfect.  Changes are expected as experience with
  307. implementation and testing is gained prior to draft standard.
  308.  
  309. Several things are unclear.  Braden is one of the authors of the
  310. documents, as is Van Jacobsen.  It is unknown whether Jacobsen in fact
  311. desires to delay the standardization of these protocol extensions.  If
  312. both authors wish to withdraw the specification from consideration,
  313. the IESG agreed that is should not push the specification forward.
  314. There are now two other proposals for extending the TCP sequence
  315. space, one of which is under discussion in the End to End Research
  316. group.  A new proposal from UCL has been circulated privately.  If
  317. there are in fact competing proposals, there may be need to resurrect
  318. the TCP Large Windows working group.
  319.  
  320. ACTION: Borman -- Get a copy of the UCL TCP proposal and distribute it
  321. to the IESG.
  322.  
  323. 4.3 Distinguished Names
  324.  
  325. A preliminary discussion of the need for a Distinguished Name Service
  326. in the Internet demonstrated immediately the need for a lengthy
  327. technical discussion of this issue. There is great need for such a
  328. service, and several platforms from which it may be built.  A separate
  329. teleconference was planned, to be led by Steve Crocker and Russ Hobby.
  330.  
  331. ACTION: Hobby, S. Crocker -- Organize an agenda for the Distinguished Name
  332. Teleconference. Work with Vaudreuil to schedule an appropriate time.
  333.  
  334.  
  335. 4.4 Full Five Day IETF meetings.
  336.  
  337. The IESG received many comments during the last plenary session in
  338. Atlanta Georgia about the need to reduce the number of simultaneous
  339. working group sessions, and the need for more time to meet.  In
  340. response to this need, and with the sense of the open plenary, the
  341. IESG agreed to adjust the schedule of the next meeting to include an
  342. additional working group session and extend the schedule to run to
  343. 3:30.  
  344.  
  345. Action: Coya -- Work with the IETF Chairman to plan a revised IETF
  346. plenary agenda to include one additional working session.
  347.  
  348.